【レポート】楽天の大規模AWSネットワークインフラの運用方法 #CUS-24 #AWSSummit

本記事は5/11に行われたセッション「楽天の大規模AWSネットワークインフラの運用方法(CUS-24)」のセッションレポートとなります。

セッション概要

スピーカー:楽天グループ株式会社 グローバルテクノロジー統括部 Vice Group Manager 藤井 博貴 氏

"ネットワークエンジニア視点で大規模ハイブリッド環境でTransit Gatewayを導入したノウハウをご紹介します" 楽天グループ株式会社はAWS Summit 2020で発表した、ビジネス中核となる決済システムを含め、様々な事業体でAWSを活用しています。2020年末、更なる拡張性と可用性を目指し、AWS Transit Gatewayの導入、ならびにVGWからの接続移行を成功させました。本セッションでは、AWS Transit Gatewayに関する設計思想や移行手順、またオンプレネットワーク側の一部定型業務の自動化事例をご紹介いたします。

セッションレポート

アジェンダ

1. 専用型AWS DIrect Connect(DX)の管理体制
2. AWS Transit Gatewau(TGW)導入検討と移行
3. 定常業務の自動化(Amazon VPC向けIPアドレス管理)
4. まとめ

専用型AWS DIrect Connect(DX)の管理体制

オンプレ-AWS間の責任分解点

• インターネットからオンプレ、DX、VGWまではネットワークエンジニアが担当
  • 管理範囲が非常に広いため、負荷が大きい状態となっている
• VPC内のアプリなどはユーザー(事業部)が担当

ネットワーク周りの役割について

• ユーザーインターフェースとしてテクニカルアカウントマネージャーが存在
• ユーザーからの要望を受けると、テクニカルアカウントマネージャーが要件定義を行ったあとネットワークエンジニアと連携して内容を吟味
  • ネットワーク設計考案も実施
• 内容が固まり次第ユーザーとネットワークエンジニアで変更作業
• この体制では適材適所で業務を行うことができることがメリット
• AWSからは技術支援等の支援を適宜受けている

AWS Transit Gatewau(TGW)導入検討と移行

• TGW導入の目的
  • ネットワーク設計の簡素化
    • VPCが増加した際のピアリングが複雑になる
    • オンプレ側のVGPピア数の削減による工数の削減
    • 構成がシンプルに
  • スピーディなリージョン間接続
    • 海外への展開
      • 独自でやるとデータセンターの場所選定などを含めリードタイムがかかる
      • その点TGWだと迅速な構築が可能
  • BCP構成の展開
    • 災害時を想定

TGW導入における導入/移行プロセス

• 導入検討からギャップ分析、技術確認、検証試験、本番導入、本番移行
• 特に技術確認ではオンプレではあまり気にならないクォータが制約になる
• 必ず検証試験をすることをお勧め

TGWのクォータ

• 最初にクォータの確認をしておくことが大事
  • 特に大切だったクォータ
    • AWSからトランジット仮想インターフェースのAWSへのTGWごとのプレフィクス
    • DX接続あたりのトランジット仮想インターフェース数
    • DXGWあたりのTGW数
  • 今後の構成変更、拡張の際に確認が必要になるため注意

テスト環境の構成と移行手順

• 移行対象のVPCはPrivate VIF + VGWで接続→VPC A
• 既存VPCはDXGW、DXでオンプレと接続→VPC B
• 通信経路の制御方法
  • オンプレ側のカスタマールーターでルートマップを設定
    • 各VPCのIPアドレスのプレフィクスリスト
    • ローカルプレファレンス
  • Active側のカスタマールーターでBGPのLPの値を高くした
• 要件として既存VPC Bでは構成変更や通信断は許されない環境
• 移行後の経路としては、元々VPC AがVGW経由でアクセスしていたものをTGW経由とする
• 移行手順
  • 手順① TGW向け新規ルートマップ追加
    • カスタマールーター１、２にそれぞれルートマップCとDを作成
    • Active側のルートマップで各VPCのBGP LPを設定
  • 手順② VGW向け新規ルートマップ変更
    • ルートマップAをLPを低く設定することで、VGW経由ではなくTGW経由で通信が行われる
    • この時点では対象のVPCからの戻りの通信はVGW経由となるため非対称ルーティング
  • 手順③ 移行対象VPCのルートテーブル変更
    • 非対称ルーティングを解消するためにルートテーブルをTGWに向けるように変更変更
  • 手順④ 既存Private VIFの削除
  • 手順⑤ TGW向け新規ルートマップ修正
  • 平日日中帯に実施し、サービス影響なしで完了

TGWを導入して良かったこと

• ネットワーク設計の簡素化
• スピーディーなリージョン間接続
  • ピア数削減によるネットワークエンジニアの負荷削減
  • マルチアカウント環境における構築のプロセスは要見直し
    • 複数アカウントでリソースを共有
    • ユーザーとネットワークエンジニア間でやりとりが発生するため
• BCP構成の展開

定常業務の自動化(Amazon VPC向けIPアドレス管理)

• ネットワークエンジニアの定常作業は主に4つ
  • オンプレCustomer Router設計構築運用
  • DX運用、コスト管理
  • TGW、VGW構築運用
  • VPC向けIPアドレス管理→これを自動化

VPC向けIPアドレスの払い出しの流れ

• 以下の作業をこれまで実施
  • ユーザーからIPアドレスアサイン依頼を受領
  • IPアドレス管理DBを確認
  • オンプレとの重複確認
  • 仮のIPアドレスで再鑑
  • IPアドレス管理DB更新
• 全て手作業のため工数がかかる
• 向上心のあるエンジニアのモチベーションの低下
• 手動のためヒューマンエラーが発生した場合、サービス影響が発生する恐れもあった
• 抜本的な解決のために自動化を検討

VPC向けIPアドレスの払い出し改善後

• AnsibleとSlackを活用して全て自動化
• 工数の大幅な削減
• 担当エンジニアのモチベーション維持
• 手動による作業を減らすことにより、サービスへの影響を限りなく低くすることができた

まとめ

• TGW導入によりネットワークエンジニアの負荷削減、品質の向上を実現
• 今後はマルチリージョン化をしたい
• 大阪リージョンが使えるようになったため、西日本DCとの通信を実現したい
• LambdaやStepFunctionsなどを利用した自動化を進めていきたい
  • プレフィクスリストやVPCアタッチメントのテンプレ化

感想

Transit Gatewayへの移行手順が分かり易い図で表されていてとても勉強になるセッションでした。今後マルチアカウントでAWSを運用する場面も増えてくるかと思うので、こういったTransit Gatewayのネットワーク周りは押さえておきたいですね！